1. Field of the Invention
The present invention relates to session establishment for push-to-talk-over-cellular (PoC) group call services, and more particularly, to a method and system for providing information of a client making a first response to a newly-established network-initiated PoC group session.
2. Description of the Related Art
Significant developments in mobile communications technology and the extension of mobile communications networks have resulted in the development of a vast array of services and applications for use with a cellular phone. At the same time, demand among cellular phone users for these additional services, such as a location, multimedia and a push-to-talk (PTT) service, is increasing. The PTT service supports various supplementary functions such as an instant messenger function and a status display function, as well as a group call and a voice call which are also provided by an existing radio or a trunk radio system (TRS).
Currently, standardization of a push-to-talk-over-cellular (PoC) service that employs the PTT function in a mobile communication network is taking place. A unique feature of the PoC service is that a user can participate in a plurality of PoC sessions and can also use a call service while switching from the PoC sessions as desired. This feature is a requirement that is specified in the open mobile alliance (OMA), which is a forum for specifying mobile communications services.
FIG. 1 is a schematic diagram illustrating a conventional PoC service system. Referring to FIG. 1, a PoC client 10, as a service requester installed in a mobile station, is generally connected to a Session Initiation Protocol/Internet Protocol (SIP/IP) core network 30 that supports SIP and IP multimedia functions via an access network 20.
The PoC client 10 resides in a PoC user terminal to provide access to the PoC service. The PoC client 10 mainly serves to establish, participate in and terminate a PoC session. In addition, the PoC client 10 makes and transfers a talk burst, supports an instant personal alert and performs authentication when accessing the PoC service. Hereinafter, unless otherwise stated, the PoC client 10 is assumed to be the same as a PoC service subscriber or PoC terminal.
The SIP/IP core network 30 is connected to a PoC server 60, a GLMS (Group List and Management System) 50 and a presence server 70 in order to support the PoC service. The PoC server 60 performs a Controlling PoC Function for maintaining and managing a PoC session, or a Participating PoC Function for participating in a PoC session for a one-to-one PoC call or a one-to-two or more PoC call (group PoC call).
Functional blocks of the PoC server will be explained below with reference to FIG. 2, a schematic diagram showing the structure of an ordinary PoC server. The PoC server performs a Controlling PoC Function (CF) of controlling overall maintenance and management of a PoC session, and a Participating PoC Function (PF) of controlling maintenance and management between each PoC session, which will be explained below with reference to Tables 1 and 2.
TABLE 1Controlling PoC Function (CF)Provides centralized PoC session handlingProvides centralized Media distributionProvides centralized Talk Burst Arbitrationfunctionality including talker identificationProvides SIP session handling, such as SIPsession origination, termination, etc.Provides policy enforcement for participationin group sessionsProvides participant informationCollects and provides centralized mediaquality informationProvides centralized charging reportsMay provide transcoding between different codecsSupports Talk Burst Control Protocol Negotiation
As shown in Table 1, the CF serves to maintain and manage a PoC session. The PoC server receives requests for the floor from PoC clients, arranges an order in which to give the clients the floor, and gives the clients the floor in that order. The PoC server also distributes a talk burst, for which an arbitrary PoC client makes a request, to all other PoC clients participating in a group PoC call, and provides information of the PoC clients participating in the group PoC call.
As shown in Table 2 below, the PF manages a PoC session between the CF and each PoC client. Particularly, the PF relays the floor between the PoC client and the CF when the PoC client makes a request for the floor or when the CF gives the floor to the PoC client. In addition, the PF relays media between the CF and the PoC client, performs transcoding between different codecs, and filters one of two concurrent PoC sessions according to the choice of a PoC user when there is simultaneous talking in the two active PoC sessions.
TABLE 2Participating PoC Function (PF)Provides PoC session handlingMay provide the Media relay function betweenPoC client and Controlling PoC serverMay provide user media adaptation proceduresMay provide the Talk Burst control messagerelay function between PoC client and ControllingPoC serverProvides SIP session handling, such as SIP sessionorigination, termination, etc, on behalf of therepresented PoC client.Provides policy enforcement for incoming PoCsession (e.g. access control, incoming PoCsession barring, availability status, etc.)May collect and provide media quality informationProvides participant charging reportsMay provide filtering of media streams inthe case of simultaneous sessionsMay provide transcoding between different codecsMay support Talk Burst Control Protocol NegotiationStores the current Answer Mode and Incoming PoCSession Barring preferences of the PoCclient
In the PoC service system described above, the PoC user can input information on a group and its members to the GLMS 50 through his/her PoC terminal, and can receive information about PoC users whom he or she can call through an individual or group list transmitted from the GLMS 50. Alternatively, the information on the group and its members may be input, modified and managed in the GLMS 50 via a reliable communication network such as the Internet or an Intranet.
In order to use the PoC service, the PoC user registers his/her PoC address with the SIP/IP core network 30. The SIP/IP core network 30 stores PoC user information at the request of the PoC user. Thus, when another PoC user tries to request a group PoC call, the PoC user registers his/her information in the SIP/IP core network 30 in advance, and requests the group PoC call to his/her SIP/IP core network 30 by using group identification information transmitted from the GLMS 50. At this time, the SIP/IP core network 30 performs address determination and domain location determination by using information of the call requesting PoC user and then transfers a PoC call request to a home PoC server with which the call requesting PoC user is registered. In regard to the PoC call request, the PoC server prepares to establish a PoC session, obtains each user's information from the GLMS, and then transfers a PoC call request signal to a corresponding SIP/IP core network. When a PoC call request is made to users within an Intradomain, the PoC server performs both the CF and PF. The PoC server, which manages a call-requested PoC user, requests a PoC call to the PoC user after the SIP/IP core network performs the locating procedure, by using information it receives from the PoC user that is transmitted to the PoC server.
FIG. 3 is a schematic diagram of CF and PF blocks of a PoC server. Referring to FIG. 3, PoC clients 111, 121, 131 and 141 provide access to a CF 100 through PFs 110, 120, 130 and 140 respectively, thereby establishing a PoC session. Here, when the floor is granted to a requester qualified as a talker from the CF 100, media based on speaking of the corresponding PoC client is transmitted to each PoC client.
First, the terminating side can set up its own answering modes according to the request of a PoC user. The answering modes can be generally divided into an auto answer mode and a manual answer mode.
The auto answer mode refers to sending an immediate answer to the originating side in a corresponding network in place of the manual answer of a receiver when included in a PoC user list designated on the terminating side. The auto answer is sent instead of operating the terminal in the network because the PoC server has a function of storing the answer mode and the corresponding user list according to a request of the terminal to set up the answer mode. Meanwhile, the manual answer mode corresponds to when the user is not included in an auto answer user list or the answer is ambiguous, or when the receiver sets up all users to make the manual answer, and indicates that a PoC call request is transmitted to the user's terminal through a receiving network and a call is connected by approval of the PoC user.
Second, the PoC system is divided into an on-demand session mode and a pre-established (or early) session mode, according to the connection set up with a PoC server within a user's home network.
The pre-established session mode is designed so that the PoC user sets up a session between a PoC client and a PoC server belonging to a PoC user's home network in advance by PoC user's request. The pre-established session enables the PoC user to negotiate media parameters to be used with the PoC server in advance, and thus perform rapid call setup without renegotiating the media parameters to be used in the future between the PoC server and client. In order to set up the pre-established session, the PoC client provides supported media parameters to a Session Description Protocol Multipurpose Internet Mail Extensions (SDP MIME) body through a method of SIP INVITE, and responds to the media parameters provided from the PoC server. The PoC client sends, to the PoC user, identification information of the pre-established session for a response message received from the PoC server, together with a conference Uniform Resource Identifier (URI). When using the pre-established session, it is possible to pre-negotiate such parameters as an IP address, a port number, a codec to be used and a talk burst control protocol.
The on-demand session mode refers to a state in which the PoC user does not set up the pre-established session, and indicates that the PoC user performs a PoC call connecting procedure after receiving an INVITE message of another PoC user.
Meanwhile, the PoC specification that is being standardized in the OMA has the following features in addition to the aforementioned fundamental functions of the communication system.
First, the PoC service supports the multilateral conference function of a half-duplex communication mode, as well as various types according to an objective of the PoC group. Specifically, a PoC conference is divided into an ad-hoc PoC group, a pre-arranged PoC group and a chat PoC group according to the feature of a participating group. First, the ad-hoc and pre-arranged PoC groups involve session establishment of dial-out to request for session setup to a conference server and forwarding the session establishment request from a server (conference server) acting as a focus to each client of interest. Next, the chat PoC group involves session establishment of dial-in to a conference server because each client is aware of information of the session of interest.
Next, the setup of the answer mode according to the call request in the PoC system can be stored both in the PoC server as an element on the network and in the PoC client as a user side terminal. In particular, when being set up for the home network managing the PoC client, the answer mode is realized by the PoC server acting as the participating PoC function (PF) in the home network to which the PoC client belongs. In this manner, in the case of setting up the answer mode of the network side, the PF automatically answers the call request of the network with a session progress message as soon as the PoC call is requested by another PoC server. Thereby, the call request procedure can be easily performed as compared with the procedure where a session setup message is transmitted to the PoC client and then the PoC client answers the session setup message. Accordingly, an initial time to grant the floor can be saved.
Meanwhile, a PoC session control network including the CF sends an INVITE request message to a terminating side network, and then receives a response message. SIP messages with which the terminating side network responds may comprise provisional response messages of 1XX, successful response messages of 2XX, or error response messages of 4XX, 5XX and 6XX according to setup of the terminating side network and PF. In the case of an AUTO-ANSWER response, the CF can receive a signal SIP 183 Session Progress, thus establishing a connection between the PoC server and client in the IMS network of a call requester. A call acceptance signal of the receiver is sent as the SIP 183 Session Process or SIP 200 OK response, and transmitted to the PoC client A via the PoC servers of the CF and PF. After receiving the 200 OK response or 183 Session Progress signal from the terminating PoC server, the CF determines that the PoC call is connected and then sends a signal Floor Granted that grants a talk burst floor, to the PoC client A. Granting talk burst authority according to the response (200 OK or 183 Session Progress) can be divided into confirmed and unconfirmed types. In the case of receiving an unconfirmed response, the CF requires a buffering function.
Meanwhile, after receiving a response signal with respect to an INVITE request signal, a PoC client A of the originating side receives a Floor Granted signal sending a talk burst transmission enable signal (ring back tone) using Real-Time Transfer Protocol (RTP) Control Protocol (RTCP). The Floor Granted signal is generated from the CF having authority to arbitrate the talk burst, and sent to the PoC client via the PF managing the corresponding PoC client. Here, the Floor Granted signal can be sent without passing through the SIP/IP core network since it uses a bearer's route instead of an SIP. The PoC user who finally confirms the ring back tone sends a media stream (e.g. voice) using RTP.
The conventional session establishment process of a PoC client using a pre-established session will be described below with reference to FIG. 4.
In FIG. 4, the PoC client A 111 of an originating side forwards terminating side group information (a URI list including address information of terminating side clients) and various pieces of information for session establishment (PoC group identifier, pre-established session URI, session type URI parameter and SIP request method) through a SIP REFER message (S11 and S12), and receives a response to the SIP REFER message (S13 and S14). Then, a PoC server A 100 receiving the SIP REFER message sends an INVITE message for a session request to a corresponding address. When receiving a first response to the INVITE message, the PoC server A 100 notifies that the session is connected (S15), forwards a Talk Burst Control Protocol (TBCP) message for granting the floor to the originating side PoC client A 111 (S17), and sends media (S18).
A protocol used for the TBCP message in practice uses RTCP application (RTCP APP). The session connection and the floor are given when the terminating side makes the first response in order to swiftly granting the floor in the beginning. The foregoing procedure connects the session with the PoC user who makes the first response, sends the media, and then receives information of the users responding to the session request through a NOTIFY message (S21 and S22) and acknowledges the same through a 200 OK message (S23 and S24). The TBCP message forwards PoC group information requested by the originating side client in the form of a PoC session identifier and a PoC group identity, but does not contain information of the terminating side client who made the first response to the session request, thereby making it impossible to know to whom the user of the PoC client obtaining the floor first grants the floor. Further, a time delay results between grant and release of the floor for mutual identification of users who are initially connected, and thus constitutes inefficient use of resources.
In addition, the terminating side receiving the request for session connection fails to get information on a list of participants in an ad-hoc group, making it difficult to determine an attribute of the session in which the terminating side participates.